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REMARKS/ARGUMENTS 

Favorable reconsideration of this application in light of the following discussion is 
respectfully requested. 

Claims 1-17 and 20 are pending in the present application, Claims 1-17 and 20 having 
been amended, and Claims 18-19 and 21 having been canceled without prejudice or 
disclaimer. Thus, no new matter is added. 

In the Office Action dated April 14, 2008, Claims 18-21 were rejected under 35 
U.S.C. § 101 as directed to non-statutory subject matter; Claims 1-21 were rejected under 35 
U.S.C. §112, first paragraph, as failing to comply with the enablement requirement; Claims 
1-21 were rejected under 35 U.S.C. § 103(a) as unpatentable over McCormack et al. (U.S. 
Pat. Pub. No. 2004/0213206, hereinafter " McCormack "^ in view of Mavhew et al. (U.S. Pat. 
Pub. No. 2004/0128410, hereinafter "Mayhew"); and Claims 1-21 were rejected under 35 
U.S.C. § 103(a) as unpatentable over Ozawa et al. (U.S. Pat. No. 7,023,858, hereinafter 
"Ozawa") in view of Bailey et al. (U.S. Pat. Pub. No. 2002/010, hereinafter " Bailey "^ and in 
further view of Official Notice, citing Settle et al. (U.S. Pat. No. 6,233,253) and Coffin, III et 
aL (U.S. Pat. No. 7,281,186). 

REJECTIONS UNDER 35 U.S.C. 8101 

Claim 20 has been amended to recite a computer readable tangible storage medium 
encoded with a computer program configured to cause an information processing apparatus to 
execute a method, and thus define statutory subject matter. Thus, it is respectfully submitted 
that the 35 U.S.C. § 101 rejection of Claim 20 has been overcome. Claims 18, 19 and 21 are 
canceled, making this rejection moot with respect to these claims. 

REJECTIONS UNDER 35 U.S.C. S112 

Regarding the 35 U.S.C. §112, first paragraph rejection, page 2 of the Official Action 
appears to assert that packets from the data handling nodes and the network node are 
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equivalent, and further appears asserts that the data handling nodes are all on the same IP- 
based packet network. 

However, by way of a non-limiting example, Applicant's Figure 4 depicts the claimed 
network interface including an Enhanced Network Interface Card (ENIC) Nil to Nil 1, which 
differs from a standard network interface card. As described in Applicant's specification at 
least on pages 23-35, one of the "data handling nodes" in this interface is the network 
processor 20, which acts as the input/output to a packet based network (via an Ethernet 
switch 2 - see Figure 1). The other data handling nodes are, for example, audio/video nodes 
218 - 224 (which can route to studio equipment - e.g. see Figure 1, Network Interface 4 
(NI4) and associated VTRs 1, 2 and 3). The network processor 20 handles, for example, IP- 
based network packets. The other data handling nodes handle, for example, data routed 
internally within the network interface by use of data tags used in place of the IP packet 
headers, via packetiser/depacketiser 24. 

Accordingly, the packets received by the network processor 20 from the packet based 
network are necessarily different from those at other data handling nodes, as defined in parts 
(a) and (b) of Claim 1, respectively. Thus, the 35 U.S.C. §112, first paragraph, rejection is 
believed to be overcome. 

REJECTIONS UNDER 35 U.S.C. 8 103 
Rejection of Claims 1-21 as unpatentable over McCormack and Mavhew . 

The Official Action has rejected Claims 1-21 under 35 U.S.C. § 103 as unpatentable 
over McCormack and Mavhew . The Official Action asserts that McCormack describes all of 
the Applicant's claimed features with the exception of the case of a data packet having an 
associated packet identifier in accordance with the Applicant's claims. However, the Official 
Action cited Mavhew as describing this more detailed aspect of the Applicant's claimed 
advancements, and states that it would have been obvious, to one of ordinary skill in the art at 
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the time the advancements were made, to combine the cited references for arriving at the 
Applicant's claims. Applicant respectfully traverses the rejection. 

Applicant's amended Claim 1 recites a network interface configured to connect to a 
packet-based data network on which a plurality of different types of payload data are 
distinguished by network-based packet header data, said network interface comprising: 
a plurality of data handling nodes; and 

a routing arrangement responsive to a packet identifier configured 
to route data packets between said data handling nodes, wherein 

one of said data handling nodes is a network processor configured 
to receive one of the data packets from and configured to transmit another 
of the data packets to said packet-based network, said network processor 
configured 

a) in the case of a data packet received from said data network, 

to detect a type of payload data from said network-based 
packet header data, 

to remove said network-based packet header data from said 

packet, and 

to associate with said packet an identifier which specifies a 
route across said routing arrangement to a target data handling node and a 
data handling operation to be carried out by said target data handling node, 
and 

b) in the case of a data packet received from another data handling 
node and having an associated packet identifier, 

to detect a type of payload data from said packet identifier, 
to remove said packet identifier, 

to apply network-based packet header data in dependence 
on said packet identifier, and 
to launch said data packet onto said network. 

The Official Action cited Asynchronous Transfer Mode (ATM) Signaling element 84 
and paragraph [0069] of McCormack as corresponding to the Claim 1 recited "a plurality of 
data handling nodes." However, McCormack describes that this single component - the 
ATM Signaling element - is responsible for the creation of virtual circuits (VCs) on an 
Asynchronous Transfer Mode link (Notably packet-based network link - see [0008] of 
McCormack) and communication over them. Thus, McCormack merely describes handling 
the routing of packets to different destinations over pre-set virtual circuits (see also 
paragraphs [0089] and [0096] of McCormack). Hence, McCormack does not disclose or 
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suggest the claimed plurality of data handling nodes, and, therefore cannot provide a network 
interface as defined in Claim 1 . 

Accordingly, for similar reasons, McCormack does not disclose a data handling node 
configured to associate with a packet an identifier (not being a network based packet header) 
which specifies a data handling operation to be carried out by a target data handling node, as 
recited Claim 1 . At best, data routing in McCormack is specified by the SVC/SVP/Channel 
ID. However, there is no separate feature of such an ID that specifies a data handling 
operation. Moreover, data routing in McCormack is different than the data handling as 
claimed. 

Further, the Official Action cited paragraph [0072] of McCormack as corresponding 
to the Claim 1 recited "a) in the case of a data packet received from said data network, to 
detect a type of payload data from said network-based packet header data," asserting that 
McCormack teaches making "intelligent decisions regarding how to transport different types 
of data through a network." However, paragraphs [0063] to [0075] of McCormack describe 
that the MPCS is either explicitly informed about a packet's contents (via the call server CS) 
or determines the contents from an initial call setup process (see also paragraph [0089]). 
Hence, McCormack does not disclose or suggest a network processor. . .configured to detect a 
type of payload data from the network-based packet header data as claimed. 

Furthermore, the Official Action cited paragraph [0083] of McCormack as 
corresponding to the Claim 1 recited "a) in the case of a data packet received from said data 
network, to associate with said packet an identifier which specifies a route across said routing 
arrangement to a target data handling node," asserting that McCormack teaches "the UDP 
and IP headers (or specified route) are added to the payload." Indeed, paragraph [0083] of 
McCormack states "[t]o route the payload through an IP network, UDP and IP headers are 
added. . . ." In contrast, the claimed network interface contains the relevant routing 
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arrangement, and an identifier specifies a route across said routing arrangement to a target 
data handling node. Moreover, the claimed identifier is a replacement for a network-based 
packet header. See page 26, lines 4-21 of Applicant's specification. Therefore, McCormack 
differs from the claimed network interface in that McCormack is directed to routing through 
an IP network, and is not wholly within the network interface itself. Further, McCormack is 
directed to a network-based packet header such as UDP or IP, whereas the identifier in Claim 
1 part (a) specifically replaces such a header. 

Moreover, the Official Action cited paragraph [0098] of McCormack as 
corresponding to the Claim 1 recited "a) in the case of a data packet received from said data 
network, to remove said network-based packet header data from said packet," asserting that 
McCormack teaches stripping the header from the packet. However, paragraph [0098] - 
[0099] and Figure 4 of McCormack describe how an IP-AAL2-IP communication is 
achieved. The source IP data in McCormack has its packet header removed by the first 
MPCS. The payload is then sent (using the ATM signalling component discussed above) 
according to a predetermined virtual path (i.e. a static address) over the AAL2 network in 
accordance with the ATM model (see also paragraph [0096]). Meanwhile, the original IP 
header is sent via a UDP/IP link (see also paragraph [0097]). As described in paragraph 
[0099], the second MPCS receives the payload from the virtual path, and then also receives 
the original IP header from the separate UDP/IP link and recombines them. 

Accordingly, McCormack describes stripping the IP header at a first network 
interface, then sending the payload over a pre-established route on another network, and then 
re-attaching the header at a second network interface that receives the payload from that other 
network. In combination with paragraph [0083] discussed above, this feature in McCormack 
is asserted as correlating with the claimed removal of the network-based packet header from 



13 



Application No. 10/812,167 

Reply to Office Action of April 14, 2008 

said packet and the association with the packet of an identifier for routing the packet within 
the network interface to another data node of the network interface. 

Applicant points out the following differences between the claimed invention and 
McCormack in light of the previous two paragraphs. First, the route/virtual path in 
McCormack is over a network between two MPCS's. By contrast, the claimed route is 
internal to a single network interface. Second, the route/virtual path in McCormack is preset 
at call setup (see Paragraph [0089]). By contrast, claimed route is responsive to the 
appropriate target of that individual data packet. Third, the operability of the network in 
McCormack relies on the feature that the IP header is necessarily sent to the second MPCS 
via a separate route, and that it is reattached to the payload data, as described both in 
paragraphs [0098] and [0099], Applicant's respectfully submit that only by impermissible 
hindsight reconstruction would one know how to avoid such a configuration. By contrast, the 
claimed IP header is neither re-routed nor re-used. 

Therefore, for all of the above reasons, McCormack does not disclose or suggest "a 
network interface," as defined in Claim 1, and Mavhew does not cure this deficiency. 
Consequently, as McCormack and Mavhew do not disclose or suggest all the elements of 
Claim 1, Claim 1 (and Claims 2-16 dependent therefrom) is patentable over McCormack in 
view of Mavhew . 

Rejection of Claims 1-21 as unpatentable over Ozawa and Bailey and Official 

Notice. 

The Official Action has further rejected Claims 1-21 under 35 U.S.C. § 103 as 
unpatentable over Ozawa and Bailey . The Official Action asserts that Ozawa describes all of 
the Applicant's claimed features with the exception of the case of a data packet having an 
associated packet identifier in accordance with the Applicant's claims. However, the Official 
Action cited Bailey as describing this more detailed aspect of the Applicant's claimed 
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advancements, and states that it would have been obvious, to one of ordinary skill in the art at 
the time the advancements were made, to combine the cited references for arriving at the 
Applicant's claims. Further, the outstanding Office Action takes Official Notice that both 
"the data type or payload type based on the packet ID" and "a demultiplexing operation 
could remove the unneeded header information to prepare the data to be displayed" are well 
known in the art. Applicant respectfully traverses the rejection. 

The Official Action cited Internet 44 of Figure 1 of Ozawa as corresponding to the 
previously recited "a network interface connectable to a packet-based data network on which 
a plurality of different types of payload data are distinguished by network-based packet 
header data." Further, the Official Action appears to cite either service provider 10 or service 
provider host 38 of Ozawa as corresponding to the claimed network interface, as service 
provider 10 and service provider host 38 are the only present elements which can be 
interpreted as being connected to the Internet 44. It is noted that Figure 1 of Ozawa refers to 
an exemplary system, and is not specifically directed to the invention of Ozawa . 

The Official Action further cited the service provider 10 of Ozawa as corresponding 
to the claimed plurality of data handling nodes. In light of the previous paragraph, this would 
imply that either the service provider 10 is cited as corresponding to both the claimed 
network interface and the claimed data handling nodes, or that the data handling nodes 
(service producer 10 of Ozawa) must contain the network interface (service provider host 38 
of Ozawa) . However, neither arrangements properly corresponds with the network interface 
as defined in Claim 1 . 

Further, the Official Action cited Col. 5, lines 36-59 of Ozawa as corresponding to the 
previously recited "a routing arrangement responsive to a packet identifier for routing data 
packets between said data handling nodes, in which one of said data handling nodes is a 
network processor for receiving one of the data packets from and transmitting another of the 
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data packets to said packet-based network," asserting that Ozawa teaches a demultiplexer and 
packet ID, audio, video, data type. Column 5, lines 36-59 of Ozawa describes Figure 2, 
which depicts a typical system configuration for a set top box 22 and the features described 
are part of an entirely separate device that is linked to the service provider 10 by a cable or 
satellite link. Thus, Ozawa in no way discloses a network interface (service provider 10 or 
host 38 of Ozawa ) comprising a routing arrangement (elements of the set-top box 22 of 
Ozawa) as claimed. Rather, Ozawa explicitly describes that they these elements are wholly 
separate, remote devices. 

Column 3, lines 44-66 of Ozawa was cited in the Action as corresponding to the 
claimed "b) in the case of a data packet received from another data handling node and having 
an associated packet identifier, to detect a type of payload data from said packet identifier, to 
remove said packet identifier, to apply network-based packet header data in dependence on 
said packet identifier, and to launch said data packet onto said network," asserting Ozawa 
teaches table ID filtering. However, this passage merely lists different transmission media by 
which TV channels can be sent to a set-top box (cable, satellite, etc.). 

Indeed, table ID filtering, as described in Col. 1, lines 49-58 and Col. 8, lines 48-58 of 
Ozawa , is used in relation to demultiplexing the transport stream received by the set-top box. 
Hence, with respect thereto, Applicant respectfully submits (1) the set top box 22 is an 
entirely separate entity from the service provider 1 0 and cannot reasonably be construed as 
being contained within service provider (Claim 1 "network interface, comprising.."), and (2) 
data is received at the set top box for display or for use within the set top box. Accordingly, 
there is no disclosure of a "network-based packet header data in dependence on said packet 
identifier, and to launch said data packet onto said network," as recited in Claim 1 . In fact, 
the set top box of Ozawa is an end-point for the data. Hence, Ozawa does not disclose or 
suggest "a network interface," as defined in Claim 1 . 
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To remedy the deficiencies of Ozawa, the Official Action takes Official Notice that 
Settle teaches "the data type or payload based on the packet ID," and that Coffin teaches "a 
demultiplexing operation could remove unneeded header information to prepare the data to 
be displayed." However, Settle and Coffin do not cure the deficiencies of Ozawa argued 
above. 

Therefore, for all of the above reasons, Ozawa does not disclose or suggest "a 
network interface," as defined in Claim 1 , and Bailey and Official Notice do not cure this 
deficiency. Consequently, as Ozawa . Bailey , and Official Notice do not disclose or suggest 
all the elements of Claim 1, Claim 1 (and Claims 2-16 dependent therefrom) is patentable 
over Ozawa in view of Bailey for all of the above reasons. 

Regarding the rejection of Claims 17 and 20, these claims recite features similar to 
Claim 1, however independent Claim 17 is a method claim and independent Claim 20 is a 
computer readable storage medium claim. Accordingly, just as McCormack , Mayhew . 
Ozawa and Bailey do not disclose or suggest all of the elements in Claim 1, similarly, 
McCormack . Mayhew . Ozawa and Bailey do not disclose or suggest all of the elements in 
Claims 17 and 20. Accordingly, it is respectfully submitted that McCormack . Mayhew . 
Ozawa and Bailey do not anticipate or make obvious the features of Claims 17 and 20. 
Therefore, Claims 17 and 20 are believed to patentably define over this applied art. 
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CONCLUSION 

Consequently, in view of the present amendment and in light of the above discussion, 
the outstanding grounds for rejection are believed to have been overcome. The application as 
amended herewith is believed to be in condition for formal allowance. An early and 
favorable action to that effect is respectfully requested. 

Respectfully submitted, 
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